This application claims priority from a commonly-owned, co-pending provisional application Ser. No. 60/002,134 filed Oct. 31, 1995, entitled "Code Analyzer" (attorney docket no. 1052-30-137).
This invention relates to software maintenance.
More particularly, the invention relates to the systematic identification and verification of software characteristics.
The use of formal methods (i.e., software development techniques emphasizing the logical properties of a program rather than its operational behavior) for supporting the design of new software is recognized as desirable by some segments of the software development community. See, D. Craigen, et al., Formal Methods Reality Check: Industrial Usage, IEEE Transactions on Software Engineering (February 1995), and J. P. Bowen, et al., Seven More Myths of Formal Methods, IEEE Software (July 1995). This is particularly true where stringent demands for reliability and/or safety encourage the investment of an additional verification effort. See, G. Bernst, et al., Experience with Black-Box Testing from Formal Specifications, AQuIS93, Venice, Italy (1993). The suggested advantages of the use of formal methods in designing new software are, however, disputed by some as being mostly anecdotal and not supported by precise measurements. See, N. Fenton, How Effective are Software Engineering Methods?, AQuIS93, Venice, Italy (1993). Furthermore, the use of formal methods for supporting new developments does not take into consideration a very large portion of existing software work, i.e., software maintenance.
The use of formal methods in software maintenance has been described in recent publications, i.e., M. P. Ward, Abstracting a Specification from Code, Journal of Software Maintenance, Research and Practice, Vol. 5, p. 101-122 and M. P. Ward, et al., Formal Methods for Legacy Systems, Journal of Software Maintenance, Research and Practice, Vol. 7, p. 203-219 (1995). However, the emphasis to date has been in creating formal specifications that comprehensively describe the meaning of a particular piece of software. Once the full meaning of the software is obtained, the code will be restructured, thereby facilitating any additional maintenance work.
Such comprehensive treatment of software for purposes of maintenance is undesirable and at times simply not feasible. This is especially true when the software to be maintained consists of thousands of lines of code and a relatively narrow problem has been identified as requiring attention. To be forced to analyze an entire piece of software for the purpose of correcting only a small portion of code is inherently inefficient and expensive.
In response to this problem, techniques have been developed to "slice" large pieces of software into smaller units pursuant to a data flow technique. This method associates portions of a piece of software through data dependency. Accordingly, while data-related portions of code may be identified and collected, such association tends to be overinclusive; identifying portions of code that may reference a variable but do not affect the value of this variable.
Finally, software maintenance cannot be limited exclusively to sequentially executed programs. In practice, many sequential programs interact with each other via permanent files (databases) or in some cases through the sharing of storage (such as is the case for Cobol programs using the linkage section features). These types of non-sequential interactions are often the cause of many problems, including data contamination and deadlocks.
Accordingly, a new method or tool for analyzing software is required that avoids the inefficiencies and limitations described above.